DIST.23 「マークアップを止めるな！」
https://gyazo.com/547abfd571d368d2c4952c6ccee13145
手戻りの少ないレスポンシブデザインのチェックポイント
コーディング歴13年
FLATはコーディング新規制作受託100%
デザイナー
デザインと違うコーディングが上がる
コーディング
マークアップが厳しいデザインがある
コストが上がっている
初期
PCサイトをスマホ対応
iPhoneとiPadを基準
現在（2018）
スマートフォンファースト
アウトプットから逆算してスムーズな設計を考えた
各デバイス共通
小さい方を基準にデザイン
コンテンツは水
デバイスで状態が変化する
小さいサイズでコンテンツが溢れる
小さいサイズを基準にする
クライアント確認
「実機で見たら違った」
文字が大きい
余白が大きい
デザインをブラウザに表示して確認
デザインをブラウザで100%表示して確認
ビジネス用途のPC事情
ノートPC
モニタ解像度が低い
PC買い替え頻度が低いので
モニタサイズを改めて確認
ターゲットサイズ
スマホは320 => 600px
SEサイズを考慮
PCは1280px => 1920px
PCのチェック
デザインデータの作成1280px
横100%と固定幅要素を決める
可変パターンを実装前に確認
スマホ・タブレットのチェック
デザインデータの作成は320(@2x => 640)
幅の設計にmarginを含める
横幅を狭めても見きれない
正解パターンを見つけよう
普段からレスポンシブ実例をみる
上記チェックポイントはあくまでも１パターン。プロジェクトに合った提案をする
ターゲットサイズを決めて可変した場合の対応を決める
まとめ
ターゲットサイズ
小さい方を基準
クライアント確認は大事
良い実装
ガターがデザインにも生きている
ナビが横幅の変化でボックス内のコンテンツを折り返す
https://gyazo.com/6a68202c216e025db0761f4cfbc7933f
上がってくるデザインデータ比率
Photshop 30%
Illustrator 30%
Skecth 20%
XD 10%
マークアップの仕方は人それぞれ
表示されればいい？
実際にどういう違いが合ってどのようなものが間違いなのかを知る
書き方が違うのはなぜ？（↑問題 ↓各人の違い）
見過ごされちゃう…構文の違い
品質管理するのは実装者だけ
似がちな別の意味を表す書き方…デザイン解釈の違う
コンテンツの意図を設定しておく、できなければ相談する
コンテンツを別の意味にみなした書き方…コンテンツ解釈の違い
コンテンツは文脈でかわるのでマークアップも変わる
粒度に不相応な表現がある場合それでいいのか検討
詳しさが違う…妥当性の違い
コンテンツの意味を機械や製作者同士に対して明確にするため、詳しく書く
そのWebサイトに役立つ実装なのか？という判断
同じ意味を持つ別の書き方…実現方法の違い
CSSやJSのための調整
Webサイトの製作者や利用者が慣れ親しんだ人はコンテンツについて漠然とした認識になりうる
HTMLを書くのは表現したいことをできる限り過不足なくWebコンテンツという形にしよう
マークアップをパワーアップするWAI-ARIA
<header role="banner">
Web Accessibility Initiative
作ってる人たち
Accessible Rich Internet Applications
規約
アクセシビリティを高めるため
マークアップ言語のセマンティクスを補強するためのもの
背景
アプリケーション化するWeb
折りたたみツリーを知覚できるのは何故？
視覚ぽさから役割や状態を知覚
<div>button</div>は押せない
セマンティックにやる
<button>を使う
属性においてセマンティクスを強化する
HTMLに限らない
ホスト言語を拡張
SVGやXMLも対象
WAI-ARIAでなにができるか
役割 ：role
<ul role="tree">
これはツリーアイテム
状態：aria-*
<li role="treeitem" aria-selected="true">
これは選択されている
プロパティ：aria-*
<ul role="tree" aria-label="menu tree">
ツリーウィジェットの名前プロパティはmenu tree
これらの付与されたセマンティクスはどのように支援技術に伝わるか
アクセシビリティAPI
OSが支援技術にセマンティクスなどの情報を伝えるAPI
https://gyazo.com/20d7d98c7421ac36193ab3fc56bafbed
WAI-ARIAをいつ使うのか
aria-label
可視ラベルが使用できない場所で不可視ラベルを提供できる
ビジュアルを推した結果ラベルが不在になる
スクリーンリーダーで読み上げられる
aria-labelledby
離れた要素のテキストをラベルとして使う
タブ
role="tablist"
role="tab"
role="tabpanel"
aria-selected
ライブリージョン
例
チャット
株価表示ウィジェット
スポーツのテキスト実況
フォームの入力エラー
aria-live="polite"
ライブリージョンロールは暗黙のaria-liveを持つが、暗黙の~に対応していないUAのために併記することが多い。
WAI-ARIAの前に
そもそも必要？
見出しがちゃんと付けばいいんちゃう？
そこ本当にアコーディオンな必要ある？
そこ本当にタブな必要ある？
なんで英語？
そうはいかない世の中
コンテンツ／ライティングの世界観
100vhに納めたいデザイン
その場でエラーを伝えたいフォーム
まずはしっかりと情報設計
セクショニング
見出し要素
表、リスト、引用、図版
a要素、button要素
alt
その上でWAI-ARIA対応
a要素内のテキストだけで伝わるか？
アコーディオン
タブ
ライブリージョン